home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13264 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.5 KB  |  162 lines
  1. Path: howland.reston.ans.net!psinntp!psinntp!psinntp!psinntp!usenet
  2. From: grantp@usa.pipeline.com(Pete Grant)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: object creation from an abstract base class
  5. Date: 24 Mar 1996 15:37:33 GMT
  6. Organization: Kalevi, Inc.
  7. Message-ID: <4j3q7t$f3i@news1.h1.usa.pipeline.com>
  8. References: <4j27q0$shm@arl-news-svc-3.compuserve.com>
  9. NNTP-Posting-Host: 38.8.120.9
  10. X-PipeUser: grantp
  11. X-PipeHub: usa.pipeline.com
  12. X-PipeGCOS: (Pete Grant)
  13. X-Newsreader: Pipeline v3.5.0
  14.  
  15. On Mar 24, 1996 01:16:48 in article <Re: object creation from an abstract
  16. base class>, 'Philippe Verdy <100105.3120@compuserve.com>' wrote: 
  17.  
  18.  
  19. >Wang TianXing <gztxwang@public1.guangzhou.gd.cn> s'Θcrit : 
  20. >> On 23 Mar 1996 18:22:26 GMT, grantp@usa.pipeline.com(Pete Grant) 
  21. >> wrote: 
  22. >>  
  23. >> | On Mar 21, 1996 08:59:50 in article <Re: object creation from an
  24. abstract 
  25. >> | base class>, 'Sukanta Ganguly <sukanta_ganguly@novell.com>' wrote:  
  26. >> |   
  27. >> |   
  28. >> | >Michael Catello wrote:  
  29. >> | >>   
  30. >> | >> Hello OOPsters,  
  31. >> | >>   
  32. >> | >> I was just looking for validation/other suggestions for a method I 
  33.  
  34. >> | >> recently used in a program. I have defined an abstract base class  
  35. >> | >> (i.e. contains pure virtual functions), all access to the derived  
  36. >> | >> classes of this base are thru a pointer to the base class. To
  37. create  
  38. >> | >> the actual objects of the derived classes I used the following
  39. scheme:  
  40. >> | >>   
  41. >> | >> enum FooType {BAR, BAS};  
  42. >> | >>   
  43. >> | >> // base class  
  44. >> | >> class CFoo  
  45. >> | >>         {  
  46. >> | >>         CFoo();  
  47. >> | >>         ~CFoo();  
  48. >> | >>   
  49. >> | >>         static CFoo* CreateFoo(FooType type);  
  50. >> | >>   
  51. >> | >>         // other methods/data including pure virtual fns whose  
  52. >behaviour 
  53. >> |   
  54. >> | >will  
  55. >> | >> be defined in the derived classes  
  56. >> | >>         };  
  57. >> | >>   
  58. >> | >> class CBar: public CFoo  
  59. >> | >>         {  
  60. >> | >>         //  
  61. >> | >>         };  
  62. >> | >>   
  63. >> | >> class CBas: public CFoo  
  64. >> | >>         {  
  65. >> | >>         //  
  66. >> | >>         };  
  67. >> | >>   
  68. >> | >> CFoo* CFoo::CreateFoo(FooType type)  
  69. >> | >>         {  
  70. >> | >>         CFoo* pfoo = NULL;  
  71. >> | >>   
  72. >> | >>         switch (type)  
  73. >> | >>                 {  
  74. >> | >>                 case BAR:  
  75. >> | >>                         pfoo = new CBar;  
  76. >> | >>                         break;  
  77. >> | >>                 case BAS:  
  78. >> | >>                         pfoo = new CBas;  
  79. >> | >>                         break;  
  80. >> | >>                 }  
  81. >> | >>   
  82. >> | >>         return pfoo;  
  83. >> | >>         }  
  84. >> | >>   
  85. >> | >> main()  
  86. >> | >>         {  
  87. >> | >>         CFoo* interface = CFoo::CreateFoo(BAR);  
  88. >> | >>         }  
  89. >> | >>   
  90. >> | >> Obviously it is the CreateFoo() function that I am wondering about.
  91. In  
  92. >> | >> the actual implementation I had multiple static "Create" functions
  93. for  
  94. >> | >> the base class that would allow me to create a new object: one
  95. based  
  96. >> | >> on an enumerated token (shown above), another an existing object,
  97. as  
  98. >> | >> well as one based on the format of a datafile. My application never
  99.  
  100. >> | >> references any of the derived classes directly, except in their  
  101. >> | >> creation and definition.  
  102. >> | >>   
  103. >> | >> Is there another/better/more appropriate way to handle this type of
  104.  
  105. >> | >> object creation? Thanks for your assistance,  
  106. >> | >>   
  107. >> | > [incorrect things deleted] 
  108. >> |   
  109. >> | BTW, the statement "pfoo = new CBas;" is perfectly legal,  
  110. >> | and even proper.  Any compiler that "cribs" about it is wrong.  
  111. >>  
  112. >> So, the original poster should write code like this: 
  113. >>  
  114. >>     CFoo *interface = new CBar; 
  115. >>  
  116. >> and remove the static function CFoo::CreateFoo(FooType); 
  117. >>  
  118. >No ! We need such a function in many C++ programs which have 
  119. >to manage presistent collections of objects. However, such 
  120. >applications do not use an enumeration but a registration 
  121. >base class which is called by adding a static member to each 
  122. >derived class, which will register themselves and obtain a 
  123. >valid Id collected on a persistent stream. But on the final 
  124. >result, managing such collections require that we have a 
  125. >CFoo::CreateFoo(FooType) function in order to recreate the 
  126. >collection of objects from a source which only enumerates 
  127. >FooTypes. This is useful to create containers of graphic 
  128. >objects with common attributes, and varying parameters 
  129. >stored on a persistent stream, so that we can load and draw 
  130. >the collection of objects without knowing anything on them. 
  131. >Your code is legal Wang but you can generalize it to avoid 
  132. >the switch() and the enumeration. 
  133. >Philippe Verdy 
  134.  
  135. I tried to condense this thread, but couldn't find anything to 
  136. delete without losing content.  Sorry about the bandwith use. 
  137.  
  138. Philippe: 
  139.  
  140. How can the code be generalized to avoid the switch()?  I 
  141. mean completely avoid it; not just hide it inside another 
  142. class or function.  
  143.  
  144. I'm not familiar with the "registration base class" idiom. 
  145. Where can I find more info on it?  From your description, I 
  146. get the impression that you generate the equivalent of an 
  147. enumeration at run time -- but that can't be.  If you 
  148. generate a different ID the next time you run the program, 
  149. your file becomes invalid.  If you guarantee that the ID 
  150. is the same each time, then it's just a substitute for 
  151. enumeration. 
  152.  
  153. In any case, the bottom line appears to be that you still 
  154. need to write the type info into the file, and upon restoration 
  155. of objects, the type info must be examined and operator 
  156. new called based on the type info.   
  157.  
  158. -- 
  159. Pete Grant 
  160. Kalevi, Inc. 
  161. Software Engineering & development
  162.